Windows Server 2003 Security Configuration (part 2) - Creating Role-Specific Server Configurations

Creating Role-Specific Server Configurations

The Windows Server 2003 default configuration is far more secure than those of previous versions of the Microsoft Windows operating system, but there are still security settings you should consider modifying from their defaults. By creating a baseline, or standard, security configuration, you can then apply additional modifications based on server roles.

Baseline Security Configuration

The security requirements for the various servers on your network might differ, but a good place to start is creating a security configuration for a standard member server.

By considering the audit, event log, services, and security options policies discussed in the previous section, and comparing the default settings to the needs of your environment, you can create a baseline security configuration for member servers. Once a baseline security configuration for your servers is in place, you can consider the special needs of the servers performing particular roles in your enterprise. Domain controllers, infrastructure servers, file and print servers, and application servers all are vulnerable to unique threats, and their security requirements can be quite different.

By combining the policy settings in a role-specific GPO with those in your baseline configuration, you can create a secure environment for each server role without much duplication of effort.

Securing Domain Controllers

On a Windows Server 2003 network that uses Active Directory, no servers are more vital than the domain controllers. Because domain controllers provide authentication services for most network operations and store and distribute group policies, their failure or compromise can be a catastrophe for network productivity. The domain controller role requires special security considerations that go beyond those of a baseline configuration.

Isolating Domain Controllers

Because of the importance of domain controllers, your security measures should minimize the threats to the computers in every possible way. Physically, domain controllers should always be in a secured location, such as a server closet or a data center that is accessible only to administrative personnel who have reason to be there. Secure the console with a complex password so that even people who are in the room for other reasons are not able to access the server.

In addition to limiting physical access to your domain controller, you should limit the access provided by the network connection. This means reducing the number of open ports on the computer by minimizing the number of applications and services it runs. Many domain controllers running Windows Server 2003 also run the DNS Server service because DNS is intimately associated with Active Directory, but you should avoid running services and applications that are unnecessary to the domain controller role.

Setting Audit and Event Log Policies

When you install Active Directory on a computer running Windows Server 2003 and create a new domain, the system puts the domain controller’s computer object in an organizational unit named Domain Controllers. The Default Domain Controllers Policy, one of two GPOs that are created by default when you install the first domain controller in a domain, is linked to the Domain Controllers OU. The Default Domain Controllers Policy provides some additional security settings beyond the default settings in the Default Domain Policy linked to the domain, but you might want to augment or modify them. Domain controllers are thus automatically configured for their role by the Default Domain Controllers Policy

For example, the Default Domain Controllers Policy enables the following audit policies, but configures them to audit only successes:

• Audit Account Logon Events

• Audit Account Management

• Audit Directory Service Access

• Audit Logon Events

• Audit Policy Change

• Audit System Events

Depending on the policy settings you use in your baseline security configuration, you might want to modify these settings to audit failures as well as successes, or to define additional policies such as Audit Object Access and Audit Process Tracking. If you decide to implement additional audit policies, be sure to consider the Event Log policies as well, because you might have to specify a larger maximum size for the security log to hold all the entries that these policies create.

Assigning User Rights

The Default Domain Policy contains no user rights assignments, but the Default Domain Controllers Policy does. Most user rights assigned by policies in the Default Domain Controllers Policy are intended to give administrators the privileges and logon rights they need to manage the domain controller, while granting users only the minimum rights they need to access the domain controller’s services. For the most part, the settings for the User Rights Assignment policy in the Default Domain Controllers Policy are acceptable, and you should use them on your domain controllers. However, there are a few changes you might want to make.

• Debug Programs The Debug Programs user right enables you to use a debugging tool to access any process running on the computer or even the operating system kernel itself. Software developers use these tools to debug applications they are in the process of creating. This user right provides access to sensitive areas of the operating system that a potential intruder might be able to abuse. By default, the GPO linked to the Domain Controllers organizational unit grants this right to the Administrators group. However, if no one in your organization is developing or debugging software, you can revoke the Debug Programs user right from the Administrators group and close what could be a serious security breach.

• Add Workstations To Domain By default, all authenticated users have the right to add up to 10 computer accounts to an Active Directory domain. Adding an account creates a new computer object in the Computers container. Computer accounts are full security principals in Windows Server 2003, able to authenticate and access domain resources. This right can allow any authenticated user to create unauthorized domain workstations that an intruder could use when the computer account is idle.

  Many large network installations rely on IT support personnel to install new workstations and manually create new computer objects. In this case, you can revoke the Authenticated Users group’s Add Workstations To Domain right without causing problems.

• Allow Log On Locally The Allow Log On Locally user right enables specified users and groups to log on to the computer interactively from the console. Obviously, users with this right have access to many important operating system elements and could cause a great deal of damage, either accidentally or deliberately. It is therefore important to grant this right only to users and groups that absolutely need it.

  The Default Domain Controllers Policy grants the Allow Log On Locally user right to the following built-in groups:

  • Account Operators

  • Administrators

  • Backup Operators

  • Print Operators

  • Server Operators

  How (or whether) you use the built-in groups is your decision, but based on their intended use, the Account Operators and Print Operators groups typically do not need to perform their tasks from a domain controller console, so you can usually revoke these two groups’ Allow Log On Locally right.

• Shut Down The System You should control the ability to shut down a domain controller very carefully, because shutting down a domain controller can affect systems all over the network. The Default Domain Controllers Policy grants this user right to the following groups:

  • Administrators

  • Backup Operators

  • Print Operators

  • Server Operators

  In most environments, members of the Backup Operators and Print Operators groups should not need to shut down a domain controller, so you can revoke their right to do this.

Configuring Services

In addition to the services required by member servers, as listed earlier in Table 9-1, domain controllers require the following additional services, which you should enable with the startup type set to Automatic:

• Distributed File System

• File Replication Service

• Intersite Messaging

• Kerberos Key Distribution Center

• Remote Procedure Call (RPC)

Securing Infrastructure Servers

Infrastructure servers are computers that run network support services such as DNS, DHCP, and Windows Internet Name Service (WINS). An infrastructure server can run any or all these services and might also fill other roles, such as an application or file and print server.

For an infrastructure server that provides all these services, you should enable the following services with the startup type set to Automatic:

• DHCP Server

• DNS Server

• NT LM Security Support Provider

• Windows Internet Name Service (WINS)

Configuring DNS Security

It is common for administrators to run the DNS Server service on Windows Server 2003 domain controllers, particularly when they use Active Directory–integrated zones. One benefit of storing the zone database in Active Directory is that the directory service takes over securing and replicating the DNS data. However, even if you do use Active Directory–integrated zones, there are additional security measures you might consider.

• Protecting Active Directory–Integrated DNS When you create Active Directory–integrated zones on your DNS server, the zone database is stored as part of the Active Directory database, which protects it from direct access by unauthorized users. However, you should still take steps to ensure that the MicrosoftDNS container object in Active Directory (shown in Figure 3) is secure.

  Figure 3. The MicrosoftDNS container in the Active Directory Users And Computers console

  

  Tip

  To access the MicrosoftDNS container object in the Active Directory Users And Computers console, you must first select the Advanced Features option from the console’s View menu. The console then displays additional containers, including the System container, which contains MicrosoftDNS.

  
  

  By default, the DnsAdmins, Domain Admins, and Enterprise Admins groups all have the Full Control permission for the MicrosoftDNS container. The local Administrators group lacks the Full Control permission, but it does have the permissions needed to create new objects and modify existing ones. You might modify these defaults to limit the number of users with permission to modify this container.

• Protecting DNS Database Files For DNS zones that are not integrated into Active Directory, the zone databases are simple text files stored in the C:\Windows\System32\Dns folder by default. Windows Server 2003 creates DNS debug logs in the same folder. The permissions for this folder grant the Administrators group Full Control, while the Server Operators group receives all permissions except Full Control. The Authenticated Users group receives the permissions needed to read and execute files in this folder.

  You don’t need file system permissions to maintain the DNS zone databases using the DNS console or to access DNS server information using a client. Therefore, there is no reason for the Authenticated Users group to have file system permissions. By enabling users to view the DNS data files, you give them an opportunity to gather information about your domain that they could use to stage an attack against the network. You can safely revoke the Authenticated Users group’s permissions for this folder, and even limit the Server Operators group to read-only access, if desired.

Configuring DHCP Security

The interruption of a DHCP server’s functions might not have an immediate effect on your network, but eventually your DHCP clients’ leases will expire and they will be unable to obtain new ones. Apart from enabling the DHCP Server service itself, there is little you can do to configure DHCP using a GPO. However, there are security measures that can help to ensure uninterrupted performance.

Denial of service attacks (DoS) constitute one of the biggest threats to DHCP servers. It is relatively simple for an unscrupulous individual to create a script that sends repeated requests for IP address assignments to the server until all the addresses in the scope are depleted. Legitimate clients are then unable to obtain addresses until the bogus leases expire. Several techniques can defend against denial of service attacks, including the following:

• Use the 80/20 address allocation method Use two DHCP servers to provide addresses for each subnet, with 80 percent of the available addresses in one server’s scope and 20 percent in the other. This ensures that there are addresses available to clients, even if one of the servers is under attack.

• Create a DHCP server cluster Clustering enables you to use multiple servers to create a single network entity. If one server fails, the other servers in the cluster take up the slack.

• Monitor DHCP activity You can monitor the activity of a DHCP server by using tools such as the Performance console and Network Monitor or by enabling audit logging on the DHCP server.

DHCP audit logging is not integrated into the main Windows Server 2003 auditing facility. You can enable DHCP audit logging by using group policies, but you cannot access the logs using the Event Viewer console. To enable DHCP audit logging, you must open the DHCP console, display the Properties dialog box for the DHCP server, and then select the Enable DHCP Audit Logging check box in the General tab. The server stores the log files in the C:\Windows\System32\Dhcp folder, by default.

Securing File and Print Servers

Security for a file and print server will most closely reflect the settings of your baseline configuration. The two main changes you must make for the file and print server role are as follows:

• Enable the Print Spooler service Use the appropriate policy in the System Services container of your GPO to enable the Print Spooler service with the Automatic startup type. The server needs this service to receive print jobs from other computers on the network.

• Disable the Microsoft Network Server: Digitally Sign Communications (Always) security policy When this security option is enabled, users are unable to view the print queue on the server, even though they are able to submit print jobs. Defining this policy with a value of Disabled in the Security Options container of your GPO ensures that your clients can access the print queue on the server.

Configuring Permissions Using a GPO

One of the most important security measures for a file and print server is protection for the user data stored on the server drives. You create this protection by using the NTFS file system on your drives and by using NTFS permissions to control access to the server drives. You can specify the permissions for your NTFS drives in a GPO by browsing to the File System container in the Group Policy Object Editor console and, from the Action menu, selecting Add File. In the series of dialog boxes that appear, you perform the following tasks:

Securing Application Servers

It is difficult, if not impossible, to create a generic security configuration for application servers, because the requirements of the individual applications are usually unique. Windows Server 2003 includes some software that enables the computer to function as an application server—most notably Internet Information Services (IIS), which provides World Wide Web, File Transfer Protocol (FTP), and other Internet server services—but in most cases, application servers run external software products, such as database or e-mail servers. To secure these applications, you must compare the security requirements of your network and your users with the security features provided by the application itself.

Applying the Principle of Least Privilege

One of the most important concepts that should guide your development and implementation of security policy is the principle of least privilege. Using this principle means that no employee and no user of information systems has more privileges or access to information and resources than they need to do their job. This principle includes removing privileges and access when employees change jobs within the organization or when they leave the company. The principle of least privilege also means that visitors to the organization or to any information resources—such as the public, contractors, temporary workers, partner representatives, and so on—should be treated in the same manner. No one, and that includes system administrators and IT workers, should have any more access or rights than they need to do their job.

There are many ways to implement and follow this maxim. The ways can be categorized according to those that are possible using security templates and those that require other mechanisms to implement. This subject is broad, and the following lists are by no means comprehensive. Instead, they are meant to teach the paradigm.

Least Privilege Opportunities in Security Templates

The following opportunities can be addressed in GPOs or in security templates that can be applied to computers or deployed using GPOs:

• Develop a strong password policy to keep unauthorized individuals off systems.

• Assign user rights sparingly. Reduce rights, especially access and logon rights, as much as possible. Set different rights on computers with different roles.

• Use security options to block access and restrict activity.

• Use file and Registry ACLs.

• Use the Restricted Groups section to force and limit membership in sensitive groups.

• Use the System Services section to disable services and restrict who can manage them.

• Develop a baseline plan for every computer role and implement using templates that are imported into GPOs on representative OUs.

• Apply a comprehensive auditing strategy.

Other Least Privilege Opportunities

These opportunities can be addressed using tools other than security templates and GPOs:

• Group users by role so that privileges and permissions can be granted by role.

• Configure ACLs for files, folders, Registry keys, directory objects, and printers to allow only the exact access any group of users needs.

• Physically protect servers. Allow access only to authorized personnel and screen this authorization.

• Review audit logs and other logs in a search for needs to restrict further access.

• Use Web proxies to limit user access to external resources.

• Use firewalls to limit access to internal networks.